1. Field of the Invention
The present invention relates generally to techniques for maintaining programming systems, and more particularly, to methods for selecting which sets of program corrections or “patches” are to be installed in accordance with the security needs of a particular organization.
2. Description of the Related Art
When programs are installed upon a computer system, the programs are constituted of a large number of individual files which are grouped together into what may be called “filesets.” For example, in FIG. 2 at 200, a systems database is shown which lists the names of various systems (SYSTEM A, SYSTEM B, etc.) and then lists following each system's name the “filesets” that are installed upon that system and the files which each of those “filesets” contain. For example, the SYSTEM A contains the FILESETS FS1 and FS2. The FILESET FS1 is shown in FIG. 2 as containing the files FILE A, FILE B, . . . , and FILE F. Likewise, the FILESET FS2 is shown as containing the files FILE J, FILE K, . . . , and FILE P.
As time passes, both through the detection of defects in the various files and also through changes in the needs of the users of the system, corrections and improvements are made to the files that comprise a given system. These are distributed in the form of “patches” each of which contains a number of files that are basically updates and improvements to the files previously installed. It is customary to group all the files contained within a given patch into one or more filesets, and to give the filesets within a patch the same names as the filesets to which they correspond in the actual systems. Accordingly, and with reference to FIG. 3 at 300, a PATCHES DATABASE is shown. A first patch, named PATCH_5, contains a fileset named FILESET FS1 which contains only an updated copy of the single file FILE A. In practice, all computer systems containing FILESET FS1 would be updated with PATCH_5. The updating process replaces a copy of the FILE A originally installed on the system with the newly revised copy of FILE A that is contained within the patch.
Over time, further patches are issued for a given system. In FIG. 3, an additional patch, PATCH_8 contains updates for FILESET FS2 which, in this case, constitutes the single updated file FILE K. At a later time, an even newer patch, PATCH_6 issues which contains updates for both the file sets FILESET FS1 and FILESET FS2. Of necessity, the patch PATCH_6 coming later in time than the other two patches, PATCH_6 includes all the updates of the earlier patches plus some new updates. More specifically, the patch PATCH_6 includes a set of updated files named FILESET FS1 that replace both FILE A and FILE F, as well as another set named FILESET FS2 which contains replacement copies of FILE K and FILE P. As is apparent, if the SYSTEM A had not previously been updated with the patches PATCH_5 and PATCH_8, that system could be fully updated with the single patch PATCH_6 and would not need updating with the earlier patches. In that sense, the patch PATCH_6 SUPERSEDES and replaces the earlier patches, which may be called “predecessors” of PATCH_6. In the discussion which follows, a “predecessor” patch is sometimes called a “child” patch, and “predecessors” are sometimes called “children.”
FIG. 4 at 400 presents a patch tree database which illustrates a way in which the historical and shared file relationships between patches can be represented in a searchable database. In FIG. 4, the newest patch PATCH_6 is shown in a central column that is labeled ROOT PATCHES. Extending to the left from this newest patch is a patch tree structure, which in this case contains only the two patches PATCH_5 and PATCH_8 shown as two limbs of a tree that converges upon the root PATCH_6. The tree portion of FIG. 4 is labeled TREE PATCHES to distinguish it from the ROOT PATCHES portion which contains the root of the patch trees. To the left in FIG. 4 is a column labeled FILESETS which simply lists all the filesets that are contained within the root patches of the patch trees. While only one patch tree is shown in the patch tree database 400, typically such a database would contain numerous trees each having a root patch and each relating to a number of different filesets. For example, the patch trees shown in FIG. 15 at 1500 could occupy a common patch tree database 400.
FIGS. 4 and 15 also illustrate a number in parenthesis opposite the name of each patch. This number indicates the reliability of each patch. A rating of “1” indicates that a patch is new and has undergone little testing. A rating of “2” indicates that the patch has been available for use for some limited amount of time and has been installed on at least some minimal number of systems. A rating of “3” indicates that the patch has undergone some system testing. Clearly, a higher rated patch corresponds to a more tested patch and therefore a more reliable patch.
In the past, it has been customary any time a system is updated to install only the newest set of root patches that contain filesets corresponding to the filesets installed on a given system. In this manner, a system is kept up-to-date. However, some of the patches installed may not have undergone sufficient testing to suit the needs of a system that is mission critical and that should not be updated with patches until they have undergone fairly thorough testing. A trained technical expert can go through all the patches, looking at the date of each patch and estimating its reliability, and can then select patches which have been around for sufficient time so that their reliability is fairly certain. However, this is a time consuming process that can also result in erroneous selections.
Some patches may also need to be made invisible to all save certain individuals, such as programmers and beta testers. Some patches may need to be confined to “in-house” technicians or may need to be taken out of service entirely for various reasons.